\section{Security Implications}
\label{sec:security}

\subsection{Security}
\label{sec:security:sec}

Since RSHC is used to control devices within the users home, security is a critical piece of the protocol. RSHC takes several measurements to ensure authentication and robustness against fuzzing attacks. We find these aspects sufficient for operation over a closed network (e.g. when all clients are connected on the home wireless network). However, for better security that ensures confidentiality and integrity, we recommend to use RSHC over a secured session, for instance by using SSL connections for security at the transport layer. Adopting a secured connection is a must if remote clients include controllers not in a closed home network, e.g. controlling a house from afar using a smartphone application.

Following are details about the authentication and robustness against fuzzing attacks mechanisms, which are applied in the design of the protocol (at least the version proposed in this document):

\begin{description}
\item[Authentication] authentication is applied via a challenge-response scheme (detailed in \sect{sec:pdus:pdu:hs}), where the server sends the client a 16-byte challenge that the user authenticates by encrypting it using DES with a preset 8-character defined user password. This ensures that only trusted users are granted access.\\
    The user-password pairs are generated and maintained by the server. We rely on the high-level application to provide registration of new users, password maintenance etc., so that users can register to the house server and obtain valid user-password pairs, manage their password etc. As suggested in the previous section, future versions of RSHC may include registration schemes and other authentication mechanisms (e.g. private-public key pairs). Our current implementation provides a user-password storage file maintained on the server side, initialized with several usernames and passwords (saved in plain text, for demonstrative purposes only; we are aware that real-world credential storage must be secured).\\
\item[Robustness Against Attacks] another important aspect of security is not enabling adversaries that throw random streams at the protocol (fuzz attacks) disclose any information that can assist the attacker. RSHC handles that through general error messages and strict communication termination criteria, as follows:
    \begin{itemize}
    \item If an authentication response is invalid for the given user, the error message thrown back to the client does not specify what went wrong, but simply notifies an authentication error has occurred. This message is general enough to not surrender secure information (was it a wrong user? was the user valid but a wrong response -- i.e. wrong password?), yet lets the valid user know that it {\em is} in fact an authentication error and not some other error.\\
        Moreover, upon authentication error, the communication is terminated, which makes it harder for an attacker to keep throwing streams at the server, with attempts to brute force through the authentication phase.
    \item Upon any illegal message, i.e. invalid message or unexpected message at the current state of the protocol, each of the server and client throw a general error message that notifies about an illegal message, and closes the connection. The information in the error message is general enough to not disclose specifics that can assist an attacker. Moreover, closing the connection upon such error prevents multiple attempts thus make it harder for an attacker to fuzz the protocol. In addition, it prevents illegal attempts by a valid user (e.g. due to network errors) that may lead the house to an invalid state.
    \end{itemize}
\end{description}

\subsection{Security Issues}
\label{sec:security:issues}

By modern standards, DES is considered to be too insecure for many applications, due to the small 56-bit key size. Although we chose to use DES for the RSHC authentication scheme, which is vulnerable to brute-force attacks or potential reply attacks, under the assumptions of closed network operation and for proof of concept, this type of authentication is sufficient. However, to allow better security also outside a secured network, better authentication schemes should be supported in future versions (e.g. AES based challenge-response). As mentioned above, using secured socket connection (SSL) can ensure confidentiality and integrity. As discussed in the previous section, starting the communication with version agreement ensures that future versions can be extended to support new security types seamlessly without harming backwards compatibility.
